Computer programs may be written to allow different portions (e.g., threads) of the program to be executed concurrently. In order to execute different portions of the program concurrently, the computer system or the program typically includes some mechanism to manage the memory accesses of the different portions to ensure that the portions access common memory locations in the desired order.
Transactional memory systems allow programmers to designate transactions in a program that may be executed as if the transactions are executing in isolation (i.e., independently of other transactions and other sequences of instructions in the program). Transactional memory systems manage the memory accesses of transactions by executing the transactions in such a way that the effects of a transaction may be rolled back or undone if two or more transactions attempt to access the same memory location in a conflicting manner. Transactional memory systems may be implemented using hardware and/or software components.
Many software transactional memory (STM) systems allow programmers to include both transactional and non-transactional code in their programs. In order to be practically efficient and pay-for-play, STM systems may provide weak atomicity where no general guarantee is made for interaction between transactional and non-transactional code. However, some commonly used code idioms, such as forms of publication, may behave incorrectly in STM systems with weak atomicity if publication safety is not provided. Unfortunately, the provision of publication safety in some STM systems may limit scalability or fail to preserve parallelism.